A major concern in timing distribution engineering for network planning, reconfiguration, and maintenance, is the avoidance of timing loops. Timing loops occur when slave-clocks form a loop, so that the active reference input of any of the clocks is actually locked indirectly to the output of that same clock. The occurrence of timing loops is usually due to human error during the network design process, during equipment commissioning/provisioning, or during the reconfiguration of the system.
The presence of timing loops in networks has led to the deployment and provisioning of network elements that inadvertently feed themselves timing information, resulting in the timing performance within the network degrading with time and becoming unpredictable. This timing deviation, or phase, can maintain close alignment with the primary or designated timing source for quite a number of hours. This may result in the occurrence of an arbitrary frequency offset at an unpredictable time at a rate that would occur much faster if the network element (NE) were to go into “holdover” mode.
Previous methods and systems that addressed the potential risk of timing loops occurring within deployed networks have mostly been reactive in nature. As a result, when a timing loop does occur, it requires troubleshooting. This troubleshooting may involve examining engineering diagrams, if available, logging in to each network element to read the alarms, and determining the timing relationship between each network element and throughout the network. Depending on the size of the network, this process can take many hours to complete. More critically, each network element, when examined, may appear to be in an apparently normal mode of operation, so that there are no alarms raised to alert monitoring systems, or field technicians, of a timing loop occurring. So, given the distributed nature of timing degradation caused and the lack of alarms raised, the diagnosis of a timing loop from a reactive mode is extremely difficult to accomplish.
Synchronization Status Messaging (SSM) is a communications protocol used in Synchronous Optical Networks (SONET). SSM assures a network operator that all network elements are operating at a common frequency within the boundaries set by standards. As such, SSM ensures the quality of the timing references throughout the network.
In some known implementations, SSM provides timing references based on the quality of available timing sources. These timing sources include external timing from building integrated timing supplies (BITS), line timing derived from high-speed (OC-192) lines, and the internal clock in the network elements.
The S1 byte information in SSM is referred to as a quality code. Each NE can detect the quality codes that describe the incoming timing signals. Then, the timing reference protection software on the ESIs (External Synchronous Interfaces) uses the quality code information to make decisions about which timing source to select as a timing reference. Protection switches can occur as a result of a change in the incoming quality code (QC) of an active timing reference. An invalid incoming QC will raise an alarm.
SSM has two goals: to ensure an NE uses the best available timing source; and to reduce the risk of timing loops occurring between two or more network elements. With the introduction of SSM into network elements, timing loop occurrences have been significantly reduced; however, SSM does not completely eliminate the occurrence of timing loops.
Moreover, SSM cannot be used by all customers. SSM requires BITS clock generation with an output capable of a DS1 reference signal using Extended Super Frame format. Older clock sources may only be capable of Super Frame format. Therefore it is possible that a customer may not be able to utilize SSM due to their BITS source clocks. A customer may interface SSM-compatible equipment with another vendor's product (or use a pseudo-BITS timing source in the equipment) that may not be SSM capable, thus rendering the equipment unable to utilize SSM. Also, customers running DX1 on DX bays along with OC192 bays loaded with DX1 in the same system cannot utilize SSM.
Therefore, there is a need to overcome at least one of the drawbacks of the prior art, which restrict the detection of timing loops to reactive methods that may only be applied to networks that do not utilize SSM.